Мои наблюдения за обстановкой на мировом рынке. Субъективно, но непредвзято.
1 Звонил индус-HR, который 2 года назад пытался продать меня в одну компанию. Говорит, искать некого, работы нет, на хлеб не хватает. Предлагал свои услуги.
2. В чате русских экспатов в Гонконге бывший менеджер Яндекса готов заплатить 2000 $ за рекомендацию в местную компанию, если он туда устроится.
3. Француз думает переехать вместе с русской женой в Россию, чтобы получить разрешение на работу. Во Франции работу найти нереально.
4. Рекрутеры из Лондона радуются, что разрабов стало сильно проще искать. Соискатели теперь не просят офисы с массажистами, лишь бы хватало на жильё.
5. Товарищ из европейского Гугла с уровнем скилов «пройду собес не просыпаясь» переживает из-за недавних сокращений и чувствует себя не очень уверенно.
6. Знакомых в одной европейской продуктовой конторе постепенно заменяют на удалённых бангалорских индусов, оставляя старых экспертов только на самых критичных участках.
Конечно, это не объективная картина, но ещё 2 года назад такие истории звучали дико и смешно. А сегодня звучит обыденно.
Как думаете: отчего так, долго ли продлится и доберется ли тренд до России?
1 Звонил индус-HR, который 2 года назад пытался продать меня в одну компанию. Говорит, искать некого, работы нет, на хлеб не хватает. Предлагал свои услуги.
2. В чате русских экспатов в Гонконге бывший менеджер Яндекса готов заплатить 2000 $ за рекомендацию в местную компанию, если он туда устроится.
3. Француз думает переехать вместе с русской женой в Россию, чтобы получить разрешение на работу. Во Франции работу найти нереально.
4. Рекрутеры из Лондона радуются, что разрабов стало сильно проще искать. Соискатели теперь не просят офисы с массажистами, лишь бы хватало на жильё.
5. Товарищ из европейского Гугла с уровнем скилов «пройду собес не просыпаясь» переживает из-за недавних сокращений и чувствует себя не очень уверенно.
6. Знакомых в одной европейской продуктовой конторе постепенно заменяют на удалённых бангалорских индусов, оставляя старых экспертов только на самых критичных участках.
Конечно, это не объективная картина, но ещё 2 года назад такие истории звучали дико и смешно. А сегодня звучит обыденно.
Как думаете: отчего так, долго ли продлится и доберется ли тренд до России?
Первые 2,5 недели поиска работы из 8. Напоминаю, что я в Сингапуре, а поэтому через 8 недель безработного меня отсюда попрут.
Результаты
— Откликнулся на 25 вакансий, по рекомендациям — на 8
— Прошёл 15 собеседований
— Получил 0 (ноль) оферов
Выводы
Все колотят понты. Даже маленький стартап на 4 стула должен проводить не менее 5 раундов собеседований, иначе не солидно. Стандартный процесс: HR → вопросы по SOLID → кодинг-интервью → беседа с PM → беседа с основателем.
На контрасте видел рекламу Альфа-Банка: собеседуют в 2 этапа, а решение принимают за день. Молодцы!
Публичность помогает. Я поставил статус «Ищу работу» в LinkedIn и рассказал об этом друзьям и в соцсетях, в итоге мне передали контакты заинтересованных во мне людей.
Нетворкинг работает. Абсолютно все собеседования, которые у меня были, я получил благодаря нетворкингу. Мне пишут люди, с которыми я когда-то работал или онбордил в ThoughtWorks. Пишут даже знакомые знакомых. Эффективность нетворкинга настолько меня удивляет, что я решил перезаписать лекцию для нашего курса про карьеру: 3 месяца назад я недостаточно эмоционально и глубоко рассказал, насколько важен нетворкинг.
Нужно попадать в ожидания. Стоит внимательно читать каждую вакансию, понимать, что именно требуется, и рассказывать только о релевантных достижениях. Тогда у HR моментально загораются глаза, и он начинает ёрзать на кресле, представляя, как вы решите его проблемы.
Результаты
— Откликнулся на 25 вакансий, по рекомендациям — на 8
— Прошёл 15 собеседований
— Получил 0 (ноль) оферов
Выводы
Все колотят понты. Даже маленький стартап на 4 стула должен проводить не менее 5 раундов собеседований, иначе не солидно. Стандартный процесс: HR → вопросы по SOLID → кодинг-интервью → беседа с PM → беседа с основателем.
На контрасте видел рекламу Альфа-Банка: собеседуют в 2 этапа, а решение принимают за день. Молодцы!
Публичность помогает. Я поставил статус «Ищу работу» в LinkedIn и рассказал об этом друзьям и в соцсетях, в итоге мне передали контакты заинтересованных во мне людей.
Нетворкинг работает. Абсолютно все собеседования, которые у меня были, я получил благодаря нетворкингу. Мне пишут люди, с которыми я когда-то работал или онбордил в ThoughtWorks. Пишут даже знакомые знакомых. Эффективность нетворкинга настолько меня удивляет, что я решил перезаписать лекцию для нашего курса про карьеру: 3 месяца назад я недостаточно эмоционально и глубоко рассказал, насколько важен нетворкинг.
Нужно попадать в ожидания. Стоит внимательно читать каждую вакансию, понимать, что именно требуется, и рассказывать только о релевантных достижениях. Тогда у HR моментально загораются глаза, и он начинает ёрзать на кресле, представляя, как вы решите его проблемы.
Я ходил на собеседование в очень странный стартап. Как вы помните, я ищу работу, чтобы меня не попёрли из Сингапура, а потому хожу на всякие собеседования. Сегодня расскажу о беседе с Head of Product, который раньше работал в Гугле.
Перед собеседованием HR предупредил меня, что на этом этапе срезается большинство разработчиков, поскольку продукту не интересны истории о смене одной БД на другую. Это внушало оптимизм. Ещё впечатляло, что в стартапе работали ребята 35–50, от 10 лет в профильной отрасли. Большинство успело поработать в Google, BlackRock или Github. Поэтому было интересно посмотреть, как стратап строит найм таких специалистов.
Первое, что я услышал, было «наконец-то я вижу резюме, по которому видно что человек приносил пользу компании, а не кафки крутил». Следующий час я рассказывал истории как мы что-то улучшали в продукте, как мерили эти улучшения, а в конце ответа я не забывал спрашивать «а как у вас дела обстоят с этим?» Это было одно из лучших собеседований в моей жизни. Я вышел с пониманием что:
— Интервьюер читал моё резюме до собеседования, и оно ему пришлось по душе
— Я отвечал именно то, что хотел услышать интервьюер
— Я не потел, пытаясь вспомнить примеры из жизни, а просто доставал по одной из уже заранее заготовленных историй
— Правильно подготовил резюме, потому что перерыл кучу материала по подготовке резюме и провалидировал эти материалы с HR’ами и консультантами
— Лекция про behavior interview вполне рабочая: стоит записать по одной истории на каждый принцип, чтобы на собеседовании петь соловьём, а стрессовать и рефлексировать дома.
Вывод такой: чем сеньёристей люди, которым попадается резюме такого формата, тем больше они его ценят. Чтобы попасть на позицию рядового гребца, вам, конечно, такое резюме не обязательно, напишите java 5+ лет. Но если хочется попасть выше и зарабатывать много денег, то советую заглянуть на наш курс. Там не только про оформление резюме и собеседования, но и про выстраивание долгосрочной карьеры.
Хотел спросить, с чем вы больше всего испытывает трудности. Ставьте реакцию под постом, а мы подумаем, как вам помочь.
😱 Пройти кодинг интервью
😭 Пройти систем-дизайн интервью
❤️ Рассказать о своём опыте так, чтобы заслушались
😎 Как выбрать следующую компанию и не тратить ещё год в болотце
🙊 Другое, напишу в комментах
Перед собеседованием HR предупредил меня, что на этом этапе срезается большинство разработчиков, поскольку продукту не интересны истории о смене одной БД на другую. Это внушало оптимизм. Ещё впечатляло, что в стартапе работали ребята 35–50, от 10 лет в профильной отрасли. Большинство успело поработать в Google, BlackRock или Github. Поэтому было интересно посмотреть, как стратап строит найм таких специалистов.
Первое, что я услышал, было «наконец-то я вижу резюме, по которому видно что человек приносил пользу компании, а не кафки крутил». Следующий час я рассказывал истории как мы что-то улучшали в продукте, как мерили эти улучшения, а в конце ответа я не забывал спрашивать «а как у вас дела обстоят с этим?» Это было одно из лучших собеседований в моей жизни. Я вышел с пониманием что:
— Интервьюер читал моё резюме до собеседования, и оно ему пришлось по душе
— Я отвечал именно то, что хотел услышать интервьюер
— Я не потел, пытаясь вспомнить примеры из жизни, а просто доставал по одной из уже заранее заготовленных историй
— Правильно подготовил резюме, потому что перерыл кучу материала по подготовке резюме и провалидировал эти материалы с HR’ами и консультантами
— Лекция про behavior interview вполне рабочая: стоит записать по одной истории на каждый принцип, чтобы на собеседовании петь соловьём, а стрессовать и рефлексировать дома.
Вывод такой: чем сеньёристей люди, которым попадается резюме такого формата, тем больше они его ценят. Чтобы попасть на позицию рядового гребца, вам, конечно, такое резюме не обязательно, напишите java 5+ лет. Но если хочется попасть выше и зарабатывать много денег, то советую заглянуть на наш курс. Там не только про оформление резюме и собеседования, но и про выстраивание долгосрочной карьеры.
Хотел спросить, с чем вы больше всего испытывает трудности. Ставьте реакцию под постом, а мы подумаем, как вам помочь.
😱 Пройти кодинг интервью
😭 Пройти систем-дизайн интервью
❤️ Рассказать о своём опыте так, чтобы заслушались
😎 Как выбрать следующую компанию и не тратить ещё год в болотце
🙊 Другое, напишу в комментах
В ходе опроса мы выяснили, что для большинства людей самым трудным является выбор достойной компании, чтобы не оказаться снова в неприятной ситуации.
Мы обещали помочь, и вот наше предложение!
Дать универсальный совет, какой компании отдать предпочтение, невозможно. Например, кому-то сейчас может быть полезно поработать в стартапе, где он освоит новые фреймворки и технологии. Однако тот же человек через три года может выгореть от постоянной неопределенности и переработок в этом стартапе.
На наш взгляд, важно ориентироваться на долгосрочные карьерные цели. Только вы сами можете понять, чего хотите от жизни и карьеры. Здесь потребуется серьезная работа над собой и глубокое размышление. За вас мы этого сделать не сможем.
Но мы готовы предложить бесплатную карьерную консультацию для 10 человек.
Как это будет происходить:
1. Вам нужно будет подумать о том, где бы вы хотели оказаться через 5 лет, и оценить свое текущее положение.
2. Далее мы созвонимся, вместе проанализируем ваши цели, выберем подходящую компанию для следующего карьерного шага и составим дорожную карту, которая поможет вам достичь этой цели.
Что нужно сделать:
0. Важно: Участвовать могут только те, кто сейчас ищет работу или планирует сменить ее в ближайшие 2 месяца.
1. Оставить комментарий «Хочу карьерную консультацию».
2. Мы свяжемся с вами и отправим небольшую анкету.
3. По результатам анкетирования выберем 10 человек и назначим встречу.
Если вы из корчмы (это закрытый чат для выпускников курса разработка без боли и сожалений) то можете не утруждаться записью, с вами устроим отдельный созвон и все вместе детально разберем кейсы.
Мы обещали помочь, и вот наше предложение!
Дать универсальный совет, какой компании отдать предпочтение, невозможно. Например, кому-то сейчас может быть полезно поработать в стартапе, где он освоит новые фреймворки и технологии. Однако тот же человек через три года может выгореть от постоянной неопределенности и переработок в этом стартапе.
На наш взгляд, важно ориентироваться на долгосрочные карьерные цели. Только вы сами можете понять, чего хотите от жизни и карьеры. Здесь потребуется серьезная работа над собой и глубокое размышление. За вас мы этого сделать не сможем.
Но мы готовы предложить бесплатную карьерную консультацию для 10 человек.
Как это будет происходить:
1. Вам нужно будет подумать о том, где бы вы хотели оказаться через 5 лет, и оценить свое текущее положение.
2. Далее мы созвонимся, вместе проанализируем ваши цели, выберем подходящую компанию для следующего карьерного шага и составим дорожную карту, которая поможет вам достичь этой цели.
Что нужно сделать:
0. Важно: Участвовать могут только те, кто сейчас ищет работу или планирует сменить ее в ближайшие 2 месяца.
1. Оставить комментарий «Хочу карьерную консультацию».
2. Мы свяжемся с вами и отправим небольшую анкету.
3. По результатам анкетирования выберем 10 человек и назначим встречу.
Если вы из корчмы (это закрытый чат для выпускников курса разработка без боли и сожалений) то можете не утруждаться записью, с вами устроим отдельный созвон и все вместе детально разберем кейсы.
Telegram
StringConcat - разработка без боли и сожалений
Я ходил на собеседование в очень странный стартап. Как вы помните, я ищу работу, чтобы меня не попёрли из Сингапура, а потому хожу на всякие собеседования. Сегодня расскажу о беседе с Head of Product, который раньше работал в Гугле.
Перед собеседованием…
Перед собеседованием…
Forwarded from kyrillic
Please open Telegram to view this post
VIEW IN TELEGRAM
Полюби легаси, %username%
Намедни листал вакансии (нет, меня пока ещё не попёрли), наткнулся на формулировку типа «проект не легаси» и задумался. В айтишной среде под легаси всегда понимают что-то плохое, древнее и такое тоскливо-мерзкое, что не хочется и палкой трогать.
Но на деле старое — не всегда плохое. Мне попадались штуки, написанные в седом мезозое на реликтовых технологиях, которые было легче поддерживать и дорабатывать, чем многие современные поделия. В этих легасных штуках был чётких и понятный замысел, а часть решений опередили время.
Был бы я тогда поумнее, не стал бы лишний раз возмущаться отсутствию моднейших фреймворков, а повнимательнее разобрал принципы, которые были заложены в системе. До меня тогда не дошло, что эта штука проработала десятки лет и никого не достала настолько, чтобы всё сжечь и написать заново на котлине.
Попадались ли вам такие артефакты? Верите ли вы в них? Становится ли мир лучше или будущее человечества мрачно и безысходно? Нам важно это знать
Намедни листал вакансии (нет, меня пока ещё не попёрли), наткнулся на формулировку типа «проект не легаси» и задумался. В айтишной среде под легаси всегда понимают что-то плохое, древнее и такое тоскливо-мерзкое, что не хочется и палкой трогать.
Но на деле старое — не всегда плохое. Мне попадались штуки, написанные в седом мезозое на реликтовых технологиях, которые было легче поддерживать и дорабатывать, чем многие современные поделия. В этих легасных штуках был чётких и понятный замысел, а часть решений опередили время.
Был бы я тогда поумнее, не стал бы лишний раз возмущаться отсутствию моднейших фреймворков, а повнимательнее разобрал принципы, которые были заложены в системе. До меня тогда не дошло, что эта штука проработала десятки лет и никого не достала настолько, чтобы всё сжечь и написать заново на котлине.
Попадались ли вам такие артефакты? Верите ли вы в них? Становится ли мир лучше или будущее человечества мрачно и безысходно? Нам важно это знать
ВНЕЗАПНО, немного про метрики. Обычно для отслеживания работы приложений мы используем несколько приёмов:
1. Тащим все количественные штуки, которые можем найти в приложении
Количество свободных подключений в пуле БД или чём-то подобном, процент попадания в кеш, количество запросов и прочее.
Во многих случаях «ручки» для мониторинга предусмотрены заранее или даже вытащены производителями фреймворков наружу. Например, в Spring Boot можно получить инфу о состоянии пула БД.
2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему
3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.
Итого, это необходимый минимум метрик для наблюдений за приложением (ну, помимо стандартных CPU и прочего). Можно раньше пользователей увидеть, что что-то идёт не так. Также можно профилировать, гонять нагрузочные тесты и хотя бы примерно понимать, где тормозит.
Есть и более хардкорный вариант — непрерывное профилирование, когда профайлинг идёт в реальном времени и можно увидеть, где, что и сколько выполнялось, примерно как в обычной IDE. Если у вас нагруженное приложение, можно попробовать эту практику, вместо того чтобы спрашивать у админов «а чо как мне тут агента подсунуть, профайлить хотим».
1. Тащим все количественные штуки, которые можем найти в приложении
Количество свободных подключений в пуле БД или чём-то подобном, процент попадания в кеш, количество запросов и прочее.
Во многих случаях «ручки» для мониторинга предусмотрены заранее или даже вытащены производителями фреймворков наружу. Например, в Spring Boot можно получить инфу о состоянии пула БД.
2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему
3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.
Итого, это необходимый минимум метрик для наблюдений за приложением (ну, помимо стандартных CPU и прочего). Можно раньше пользователей увидеть, что что-то идёт не так. Также можно профилировать, гонять нагрузочные тесты и хотя бы примерно понимать, где тормозит.
Есть и более хардкорный вариант — непрерывное профилирование, когда профайлинг идёт в реальном времени и можно увидеть, где, что и сколько выполнялось, примерно как в обычной IDE. Если у вас нагруженное приложение, можно попробовать эту практику, вместо того чтобы спрашивать у админов «а чо как мне тут агента подсунуть, профайлить хотим».
Telegram
Microservices | Вопросы с Собеседований
⚡Continuous profiling
Continuous profiling - техника постоянного сбора данных о ресурсах, затрачиваемых приложением
Обычно профилирование применяется как ситуативная мера, чтобы здесь и сейчас подебагать перфоманс приложения. Но это не позволяет анализировать…
Continuous profiling - техника постоянного сбора данных о ресурсах, затрачиваемых приложением
Обычно профилирование применяется как ситуативная мера, чтобы здесь и сейчас подебагать перфоманс приложения. Но это не позволяет анализировать…
Please open Telegram to view this post
VIEW IN TELEGRAM
Как я получал оффер от банка
В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать.
В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, ноя тебя найду уже 3 человека сказали, что я обязан с тобой поговорить. Если нужна работа, приезжай в офис».
Первым рекомендателем оказался мой бывший коллега, Thoughtworker старой закалки. Он перешёл в этот банк несколько лет назад. Увидел мой пост и с утра пошёл к СТО сказать, что есть я, которого ещё вчера Thoughtworks предлагал им взять в аренду в 2 раза дороже, чем я сегодня стою.
Второй — мой знакомый, с которым мы жарили шашлыки и пили пиво. Тоже увидел мой пост и за утренним кофе тому же СТО сказал, что было бы неплохо меня нанять.
Но их всех опередил мой бывший проджект-менеджер, который решил позвонить этому СТО ещё вечером накануне.
В итоге я пришёл на собеседование, где мне час рассказывали, как в банке что устроено, какие есть проблемы и как они видят будущее. Я сидел и думал, когда же начать рассказ о себе. Но хвататься расхотелось, когда СТО пожаловался, что обо мне ему уже все рассказали, и не один раз. Но бедный СТО не знал, что на следующий день его ждёт встреча с Омаром — директором финсектора Thoughtworks. Драматизм ситуации в том, что это человек, который может продать что угодно кому угодно. И именно у Омара я научился отвечать на вопросы клиента, когда напрямую ответить нельзя, и заражать клиента своими идеями. Омар встретился с СТО по другому вопросу, но тоже между делом искренне меня рекомендовал, так что у банка шансов не оставалось.
Вывод: личные контакты решают. Если у вас проблема — расскажите о ней, и помощь может прийти оттуда, откуда не ждали.
В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать.
В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, но
Первым рекомендателем оказался мой бывший коллега, Thoughtworker старой закалки. Он перешёл в этот банк несколько лет назад. Увидел мой пост и с утра пошёл к СТО сказать, что есть я, которого ещё вчера Thoughtworks предлагал им взять в аренду в 2 раза дороже, чем я сегодня стою.
Второй — мой знакомый, с которым мы жарили шашлыки и пили пиво. Тоже увидел мой пост и за утренним кофе тому же СТО сказал, что было бы неплохо меня нанять.
Но их всех опередил мой бывший проджект-менеджер, который решил позвонить этому СТО ещё вечером накануне.
В итоге я пришёл на собеседование, где мне час рассказывали, как в банке что устроено, какие есть проблемы и как они видят будущее. Я сидел и думал, когда же начать рассказ о себе. Но хвататься расхотелось, когда СТО пожаловался, что обо мне ему уже все рассказали, и не один раз. Но бедный СТО не знал, что на следующий день его ждёт встреча с Омаром — директором финсектора Thoughtworks. Драматизм ситуации в том, что это человек, который может продать что угодно кому угодно. И именно у Омара я научился отвечать на вопросы клиента, когда напрямую ответить нельзя, и заражать клиента своими идеями. Омар встретился с СТО по другому вопросу, но тоже между делом искренне меня рекомендовал, так что у банка шансов не оставалось.
Вывод: личные контакты решают. Если у вас проблема — расскажите о ней, и помощь может прийти оттуда, откуда не ждали.
StringConcat - разработка без боли и сожалений
Как я получал оффер от банка В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать. В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, но я тебя найду уже 3 человека…
Пока Сережа наслаждается успехом, мы снова возвращаемся к духоте.
Коллеги скинули всё ещё актуальную заметку про предварительный анализ. Не обращайте внимания на название, суть там в другом — перед тем как что-то реализовывать, это стоит описать в доке.
Например:
— какие изменения нужно внести
— какие будут контракты
— как лучше тестировать
— etc
Я сам исповедую примерно такой подход уже в нескольких конторах. Кажется, что это бюрократия и трата времени, но в итоге у всех участников выравнивается понимание конечного результата. Особенно когда такая дока пишется сообща. Тестеры понимают, как тестить, разрабы понимают, как ревьювить и т.д. Метод сильно отличается от классического «вот вам задача в жыре, сами понимайте, что я тут имел ввиду, вы ж умные»
В итоге количество непоняток и переделок снижается в разы, легко организовать трассировку, а разработчики уходят с полным пониманием задачи и повышается точность прогнозирования сроков в сторипоинтах.
Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы
Несколько важных наблюдений
1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.
2. Документ обычно пишется на пользовательскую историю или похожий артефакт, то есть в изготовлении доки задействуются и фронтендеры и бекендеры и тестировщики, которым это потом чинить. Далее сторя разбивается на подзадачи для конкретных спецов. Фактически мы начинаем разрабатывать на бумаге, продумываем самые сложные сценарии, а кодить можно уже спинным мозгом. В этом отличие от классических требований (даже самых подробных) описываемых аналитиками.
3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.
4. Подход слабо работает в лапшекоде уровня «после просмотра промыть глазаа хлоргексидином», ибо количество непредвиденных ситуаций ломает начальную идею полностью. Хотя полностью от них избавиться не получится даже в поддерживаемом коде
Коллеги скинули всё ещё актуальную заметку про предварительный анализ. Не обращайте внимания на название, суть там в другом — перед тем как что-то реализовывать, это стоит описать в доке.
Например:
— какие изменения нужно внести
— какие будут контракты
— как лучше тестировать
— etc
Я сам исповедую примерно такой подход уже в нескольких конторах. Кажется, что это бюрократия и трата времени, но в итоге у всех участников выравнивается понимание конечного результата. Особенно когда такая дока пишется сообща. Тестеры понимают, как тестить, разрабы понимают, как ревьювить и т.д. Метод сильно отличается от классического «вот вам задача в жыре, сами понимайте, что я тут имел ввиду, вы ж умные»
В итоге количество непоняток и переделок снижается в разы, легко организовать трассировку, а разработчики уходят с полным пониманием задачи и повышается точность прогнозирования сроков
Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы
Несколько важных наблюдений
1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.
2. Документ обычно пишется на пользовательскую историю или похожий артефакт, то есть в изготовлении доки задействуются и фронтендеры и бекендеры и тестировщики, которым это потом чинить. Далее сторя разбивается на подзадачи для конкретных спецов. Фактически мы начинаем разрабатывать на бумаге, продумываем самые сложные сценарии, а кодить можно уже спинным мозгом. В этом отличие от классических требований (даже самых подробных) описываемых аналитиками.
3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.
4. Подход слабо работает в лапшекоде уровня «после просмотра промыть глазаа хлоргексидином», ибо количество непредвиденных ситуаций ломает начальную идею полностью. Хотя полностью от них избавиться не получится даже в поддерживаемом коде
Хабр
Три недели кодирования экономят два дня проектирования
Введение Об авторе Меня зовут Леонид «Лео» Царев. Я бывший программист на .Net (18+ лет опыта), последние 10 лет я тимлид/архитектор/руководитель. Сейчас я директор департамента разработки в компании...
Сергей на связи!
На новой работе увидел интересный приём, которым архитекторы кошмарят разработчиков. Спешу поделится.
Значит, у архитектора есть 2 большие задачи.
Задача раз: выработать нефункциональные требования, а потом на их основе нарисовать архитектуру. Задача сложная, но с ней более-менее большинство справляется.
Задача два: проследить, чтобы команда соблюдала заложенные в архитектуру принципы. С этим справляются уже не все, зачастую фантазии хватает только разносить всех на code review. Если у архитектора команда на 5-7 разработчиков, то так прожить ещё можно. А если у вас целый департамент на 50-70 программистов — ну такое.
Конечно, нужно автоматизировать битьё разработчиков по рукам. Например, автоматически проверять % покрытия тестами, или code style. Как правило, они интегрируются в систему сборки и запускаются автоматически, заваливая билд, если какая-то договорённость не соблюдена.
Но если репозиториев уже под сотню, и они плодятся каждый день? Тогда следить за соблюдением договорённостей помогает вот это:
— везде интегрирован jacoco, который проверяет покрытие тестами хотя бы 80%
— во всех репозиториях используется один code style
— все зависимости тянутся только из внутреннего репозитория
Делюсь подсмотренным приёмом: использовать стандартизированный gradle. Как правило, любая сборка состоит из интегрированных плагинов, конфигурация которых вручную копируется из одного проекта в другой. Но можно сделать собственный gradle wrapper со всеми установленными и настроенными плагинами.
Как работает
Архитектор один раз создёет репозиторий, который будет билдить
Далее архитектор создает обычный файл
Профит! Теперь в проект интегрировано всё минимально необходимое.
Фича зовётся gradle init scripts
Минусы
Если вдруг политики поменялись, скажем, мы резко захотели добавить какой-нибудь security плагин, то пока проекты не обновят версию грейдла, никакого чуда не произойдёт.
На новой работе увидел интересный приём, которым архитекторы кошмарят разработчиков. Спешу поделится.
Значит, у архитектора есть 2 большие задачи.
Задача раз: выработать нефункциональные требования, а потом на их основе нарисовать архитектуру. Задача сложная, но с ней более-менее большинство справляется.
Задача два: проследить, чтобы команда соблюдала заложенные в архитектуру принципы. С этим справляются уже не все, зачастую фантазии хватает только разносить всех на code review. Если у архитектора команда на 5-7 разработчиков, то так прожить ещё можно. А если у вас целый департамент на 50-70 программистов — ну такое.
Конечно, нужно автоматизировать битьё разработчиков по рукам. Например, автоматически проверять % покрытия тестами, или code style. Как правило, они интегрируются в систему сборки и запускаются автоматически, заваливая билд, если какая-то договорённость не соблюдена.
Но если репозиториев уже под сотню, и они плодятся каждый день? Тогда следить за соблюдением договорённостей помогает вот это:
— везде интегрирован jacoco, который проверяет покрытие тестами хотя бы 80%
— во всех репозиториях используется один code style
— все зависимости тянутся только из внутреннего репозитория
Делюсь подсмотренным приёмом: использовать стандартизированный gradle. Как правило, любая сборка состоит из интегрированных плагинов, конфигурация которых вручную копируется из одного проекта в другой. Но можно сделать собственный gradle wrapper со всеми установленными и настроенными плагинами.
Как работает
Архитектор один раз создёет репозиторий, который будет билдить
gradle wrapper. Он публикуется в артифактори и становится доступен для скачивания как обычный пакет.Далее архитектор создает обычный файл
build.gradle, добавляет зависимости по вкусу, типа спринга или junit, и настраивает плагины, к примеру, jacoco. Зовётся это init scripts. Архитектор публикует грейдл, рассылает всем разработчикам ссылку на него и идёт спокойно пить пиво. Теперь разработчики при создании проекта указывают, что wrapper надо скачивать не с gradle.org, а из вашего репозитория.gradle-wrapper.properties
distributionUrl=https://artifactory.your.org/repository/gradle-8.5.zipПрофит! Теперь в проект интегрировано всё минимально необходимое.
Фича зовётся gradle init scripts
Минусы
Если вдруг политики поменялись, скажем, мы резко захотели добавить какой-нибудь security плагин, то пока проекты не обновят версию грейдла, никакого чуда не произойдёт.
Первые впечатления от работы
Ситуация. Разрабатываем anticorruption layer между бравыми цифровыми сервисами банка и глючным core. Проекту три месяца. У всех разработчиков опыта минимум 7 лет. Из репозитория машет маленький-жук навозник, почти свалявший себе шарик говна. Буду вести репортаж, как мы всё это будем пересаживать на рельсы clean architecture.
Пока план такой:
1. Понять, как должно быть, и насколько мы далеки от этого
2. Найти единомышленников или хотя бы неравнодушных
3 .Разработать план рефакторинга, включив туда как можно больше людей. Чтобы все были повязаны и не саботировали потом.
4. Запихнуть задачи на рефакторинг в ближайшие спринты. Чего ждать.
На следующей неделе расскажу, как пошло.
Нам писали, что курс «Поваренная книга дядюшки Боба» тормозит. Докладываю: курс перезалит, теперь можно смотреть без регистрации, VPN и тормозов. Даже с мобилы.
Ситуация. Разрабатываем anticorruption layer между бравыми цифровыми сервисами банка и глючным core. Проекту три месяца. У всех разработчиков опыта минимум 7 лет. Из репозитория машет маленький-жук навозник, почти свалявший себе шарик говна. Буду вести репортаж, как мы всё это будем пересаживать на рельсы clean architecture.
Пока план такой:
1. Понять, как должно быть, и насколько мы далеки от этого
2. Найти единомышленников или хотя бы неравнодушных
3 .Разработать план рефакторинга, включив туда как можно больше людей. Чтобы все были повязаны и не саботировали потом.
4. Запихнуть задачи на рефакторинг в ближайшие спринты. Чего ждать.
На следующей неделе расскажу, как пошло.
Нам писали, что курс «Поваренная книга дядюшки Боба» тормозит. Докладываю: курс перезалит, теперь можно смотреть без регистрации, VPN и тормозов. Даже с мобилы.
Forwarded from DDDevotion
Почему агрегаты должны хранить свои секреты
Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат
Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде
TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:Сохранение секретов == гибкость
Когда агрегаты скрывают свою внутреннюю структуру, наша система становится гораздо более гибкой. Вы можете рефакторить внутрянку, не переживая за другие части кодовой базы. Внешние компоненты взаимодействуют с агрегатами через четко определенный интерфейс (aggregate root, корень агрегата), что делает наш код более устойчивым к изменениям.
Таким образом, скрыв внутренние детали, мы можем сосредоточиться на основных обязанностях агрегатов: выполнении бизнес-правил и поддержании согласованности. В результате, мы не только снижаем сложность, но и повышаем гибкость и поддерживаемость нашей доменной модели, облегчая реализацию будущих изменений.
Антипаттерн «Кадастровый инженер»
Хочет всё размежевать, чтобы не слиплось. Считает, что разделение по репозиториям и приложениям — панацея от скверны лапшекода. Мол, щас всё растащим, и никто не сможет использовать Х в У.
Такой подход работает, но, как всегда, есть нюанс: можно ошибиться с границей разрезания. Например, нарезать не там в микросервисах, и получим неподдерживаемое распределённое нечто.
Крайнее проявление — вынести в отдельный репозиторий каждый компонент единой системы: тесты, вёрстку, сервисы, скрипты миграций и т.д. Тогда вашей работой становится жонглирование ветками и толкание локтями коллег в репозиториях в попытках собрать всё воедино хотя бы на CI-сервере.
Чтобы разрез сильно не болел, нужно научиться искать логические границы и уметь пресекать нарушения. Потом дать границам устояться, и только потом отрезать. Попытка что-либо отрезать в бардаке приводит к ещё большему бардаку.
Как понять, что разделили неправильно? Когда для одной задачи вам приходится коммитить сразу в несколько репозиториев и в строгой последовательности. У репозиториев оказался слишком высокий coupling. Да, представьте coupling и cohesion применим и в рамках git-репозитория.
Хочет всё размежевать, чтобы не слиплось. Считает, что разделение по репозиториям и приложениям — панацея от скверны лапшекода. Мол, щас всё растащим, и никто не сможет использовать Х в У.
Такой подход работает, но, как всегда, есть нюанс: можно ошибиться с границей разрезания. Например, нарезать не там в микросервисах, и получим неподдерживаемое распределённое нечто.
Крайнее проявление — вынести в отдельный репозиторий каждый компонент единой системы: тесты, вёрстку, сервисы, скрипты миграций и т.д. Тогда вашей работой становится жонглирование ветками и толкание локтями коллег в репозиториях в попытках собрать всё воедино хотя бы на CI-сервере.
Чтобы разрез сильно не болел, нужно научиться искать логические границы и уметь пресекать нарушения. Потом дать границам устояться, и только потом отрезать. Попытка что-либо отрезать в бардаке приводит к ещё большему бардаку.
Как понять, что разделили неправильно? Когда для одной задачи вам приходится коммитить сразу в несколько репозиториев и в строгой последовательности. У репозиториев оказался слишком высокий coupling. Да, представьте coupling и cohesion применим и в рамках git-репозитория.
Небольшая заметка о стрессоустойчивости и вреде гиблых проектов https://vk.com/@-200496256-timlid-ozverel
VK
Что делать, если тимлид озверел
Читатель спрашивает: поставили нового тимлида, который орёт на всех и прямо заявляет, что знает лучше, и все должны делать, что им говоря..
Ребята из Postgres Professional написали неплохую книгу «PostgreSQL 16 изнутри»
Какие темы охватывает книга:
— Устройство shared buffer
— Как работает WAL
— Как выполняются запросы
— Зачем нам вакуум
— Как работают индексы
— Как устроен MVCC
— etc
Всего 665 страниц годноты на русском. Кому лень читать — у ребят есть ютуп-канал, посвящённый той же теме
Просвещайтесь!
#полезнота
Какие темы охватывает книга:
— Устройство shared buffer
— Как работает WAL
— Как выполняются запросы
— Зачем нам вакуум
— Как работают индексы
— Как устроен MVCC
— etc
Всего 665 страниц годноты на русском. Кому лень читать — у ребят есть ютуп-канал, посвящённый той же теме
Просвещайтесь!
#полезнота
Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг:
Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно.
В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.
Возможно, это явление массовое и происходит от общепринятого подхода в индустрии: да пофиг ваще, бизнес бабки колотит, остальное похер. В ключевых системах ожидаемо накопилась критическая масса, и техдолг начал стрелять у всех. Ну или это просто совпадение.
Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3
Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно.
В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.
Возможно, это явление массовое и происходит от общепринятого подхода в индустрии: да пофиг ваще, бизнес бабки колотит, остальное похер. В ключевых системах ожидаемо накопилась критическая масса, и техдолг начал стрелять у всех. Ну или это просто совпадение.
Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3